home *** CD-ROM | disk | FTP | other *** search
Frequently Asked Questions (FAQS);faqs.555 Motif++ is a public-domain library that defines C++ class wrappers for Motif 1.1; it adds an "application" class for, e.g., initializing X, and also integrates WCL and the Xbae widget set. This work was developed by Ronald van Loon <rvloon@cv.ruu.nl> based on X++, a set of bindings done by the University of Lowell Graphics Research Laboratory. The current sources are available from decuac.dec.com (192.5.214.1) as /pub/X11/motif++.21.jul.92.tar.Z. The source code examples for Doug Young's "Object-Oriented Programming with C++ and OSF/Motif" [ISBN 0-13-630252-1] do not include "widget wrappers" but do include a set of classes that encapsulates higher-level facilities commonly needed by Motif- or other Xt-based applications; check export in ~ftp/contrib/young.c++.tar.Z. Rogue Wave offers "View.h++" for C++ programmers using Motif; info: 1-800-487-3217 or +1 503 754 2311. A product called "Commonview" by Glockenspiel Ltd, Ireland (??) apparently is a C++-based toolkit for multiple window systems, including PM, Windows, and X/Motif. Xv++ is sold by Qualix (415-572-0200; fax -1300); it implements an interface from the GIL files that Sun's OpenWindows Developers Guide 3.0 produces to Xview wrapper classes in C++. UIT is a set of C++ classes embedding the XView toolkit; it is intended for use with Sun's OpenWindows Developers Guide 3.0 builder tool. Sources are on export.mit.edu.au as UIT.tar.Z. Version 2 was released 5/28/92. Also of likely use is ObjectCenter (Saber-C++). And a reasonable alternative to all of the above is ParcPlace's (formerly Solbourne's) Object Interface. [Thanks to Douglas S. Rand (dsrand@mitre.org) and George Wu (gwu@tcs.com);2/91] ---------------------------------------------------------------------- Subject: 135)! Where can I obtain alternate language bindings to X? Versions of the CLX Lisp bindings are part of the X11 core source distributions. A version of CLX is on the R5 tape [10/91]; version 5.0.2 [9/92] is on export.lcs.mit.edu in /contrib/CLX.R5.02.tar.Z. The SAIC Ada-X11 bindings are through anonymous ftp in /pub from stars.rosslyn.unisys.com (128.126.164.2). There is an X/Ada study team sponsored by NASA JSC, which apparently is working out bindings. Information: xada@ghg.hou.tx.us. GNU SmallTalk has a beta native SmallTalk binding to X called STIX (by Steven.Byrne@Eng.Sun.COM). It is still in its beginning stages, and documentation is sparse outside the SmallTalk code itself. The sources are available as /pub/gnu/smalltalk-1.1.1.tar.Z on prep.ai.mit.edu (18.71.0.38) or ugle.unit.no (129.241.1.97). Prolog bindings (called "XWIP") written by Ted Kim at UCLA while supported in part by DARPA are available by anonymous FTP from export.lcs.mit.edu:contrib/xwip.tar.Z or ftp.cs.ucla.edu:pub/xwip.tar.Z. These prolog language bindings depend on having a Quintus-type foreign function interface in your prolog. The developer has gotten it to work with Quintus and SICStus prolog. Inquiries should go to xwip@cs.ucla.edu. [3/90] Scheme bindings to Xlib, OSF/Motif, and Xaw are part of the Elk distribution; version 1.5a on export obsoletes the version on the R5 contrib tape. x-scm, a bolt-on accessory for Aubrey Jaffer's "scm" Scheme interpreter that provides an interface to Xlib, Motif, and OpenLook, is now available via FTP from altdorf.ai.mit.edu:archive/scm/xscm1.05.tar.Z and nexus.yorku.ca:pub/scheme/new/xscm1.05.tar.Z. Ada bindings to Motif, explicitly, will eventually be made available by the Jet Propulsion Laboratories, probably through the normal electronic means. Advance information can be obtained from dsouleles@dsfvax.jpl.nasa.gov, who may respond as time permits. AdaMotif is a complete binding to X and Motif for the Ada language, for many common systems; it is based in part upon the SAIC/Unisys bindings and also includes a UIL to Ada translator. Info: Systems Engineering Research Corporation, 1-800-Ada-SERC (well!serc@apple.com). Also: the MIT Consortium, although not involved in producing Ada bindings for X, maintains a partial listing of people involved in X and Ada; information is available from Donna Converse, converse@expo.lcs.mit.edu. ---------------------------------------------------------------------- Subject: 136) Can XGetWindowAttributes get a window's background pixel/pixmap? No. Once set, the background pixel or pixmap of a window cannot be re-read by clients. The reason for this is that a client can create a pixmap, set it to be the background pixmap of a window, and then free the pixmap. The window keeps this background, but the pixmap itself is destroyed. If you're sure a window has a background pixel (not a pixmap), you can use XClearArea() to clear a region to the background color and then use XGetImage() to read back that pixel. However, this action alters the contents of the window, and it suffers from race conditions with exposures. [courtesy Dave Lemke of NCD and Stuart Marks of Sun] Note that the same applies to the border pixel/pixmap. This is a (mis)feature of the protocol which allows the server is free to manipulate the pixel/pixmap however it wants. By not requiring the server to keep the original pixel or pixmap, some (potentially a lot of) space can be saved. [courtesy Jim Fulton, MIT X Consortium] ---------------------------------------------------------------------- Subject: 137) How do I create a transparent window? A completely transparent window is easy to get -- use an InputOnly window. In order to create a window which is *mostly* transparent, you have several choices: - the SHAPE extension first released with X11R4 offers an easy way to make non-rectangular windows, so you can set the shape of the window to fit the areas where the window should be nontransparent; however, not all servers support the extension. - a machine-specific method of implementing transparent windows for particular servers is to use an overlay plane supported by the hardware. Note that there is no X notion of a "transparent color index". - a generally portable solution is to use a large number of tiny windows, but this makes operating on the application as a unit difficult. - a final answer is to consider whether you really need a transparent window or if you would be satisfied with being able to overlay your application window with information; if so, you can draw into separate bitplanes in colors that will appear properly. [thanks to der Mouse, mouse@lightning.McRCIM.McGill.EDU, 3/92; see also The X Journal 1:4 for a more complete answer, including code samples for this last option] ---------------------------------------------------------------------- Subject: 138) Why doesn't GXxor produce mathematically-correct color values? When using GXxor you may expect that drawing with a value of black on a background of black, for example, should produce white. However, the drawing operation does not work on RGB values but on colormap indices. The color that the resulting colormap index actually points to is undefined and visually random unless you have actually filled it in yourself. [On many X servers Black and White often 0/1 or 1/0; programs taking advantage of this mathematical coincidence will break.] If you want to be combining colors with GXxor, then you should be allocating a number of your own color cells and filling them with your chosen pre-computed values. If you want to use GXxor simply to switch between two colors, then you can take the shortcut of setting the background color in the GC (graphics context) to 0 and the foreground color to a value such that when it draws over red, say, the result is blue, and when it draws over blue the result is red. This foreground value is itself the XOR of the colormap indices of red and blue. [Thanks to Chris Flatters (cflatter@zia.aoc.nrao.EDU) and Ken Whaley (whaley@spectre.pa.dec.com), 2/91] ---------------------------------------------------------------------- Subject: 139) Why does every color I allocate show up as black? Make sure you're using 16 bits and not 8. The red, green, and blue fields of an XColor structure are scaled so that 0 is nothing and 65535 is full-blast. If you forget to scale (using, for example, 0-255 for each color) the XAllocColor function will perform correctly but the resulting color is usually black. [Thanks to Paul Asente, asente@adobe.com, 7/91] ---------------------------------------------------------------------- Subject: 140) Why can't my program get a standard colormap? I have an image-processing program which uses XGetRGBColormap() to get the standard colormap, but it doesn't work. XGetRGBColormap() when used with the property XA_RGB_DEFAULT_MAP does not create a standard colormap -- it just returns one if one already exists. Use xstdcmap or do what it does in order to create the standard colormap first. [1/91; from der Mouse (mouse@larry.mcrcim.mcgill.edu)] ---------------------------------------------------------------------- Subject: 141) Why does the pixmap I copy to the screen show up as garbage? The initial contents of pixmaps are undefined. This means that most servers will allocate the memory and leave around whatever happens to be there -- which is usually garbage. You probably want to clear the pixmap first using XFillRectangle() with a function of GXcopy and a foreground pixel of whatever color you want as your background (or 0L if you are using the pixmap as a mask). [courtesy Dave Lemke of NCD and Stuart Marks of Sun] ---------------------------------------------------------------------- Subject: 142) How do I check whether a window ID is valid? My program has the ID of a window on a remote display. I want to check whether the window exists before doing anything with it. Because X is asynchronous, there isn't a guarantee that the window would still exist between the time that you got the ID and the time you sent an event to the window or otherwise manipulated it. What you should do is send the event without checking, but install an error handler to catch any BadWindow errors, which would indicate that the window no longer exists. This scheme will work except on the [rare] occasion that the original window has been destroyed and its ID reallocated to another window. [courtesy Ken Lee (klee@wsl.dec.com), 4/90] ---------------------------------------------------------------------- Subject: 143) Can I have two applications draw to the same window? Yes. The X server assigns IDs to windows and other resources (actually, the server assigns some bits, the client others), and any application that knows the ID can manipulate the resource [almost any X server resource, except for GCs and private color cells, can be shared]. The problem you face is how to disseminate the window ID to multiple applications. A simple way to handle this (and which solves the problem of the applications' running on different machines) is in the first application to create a specially-named property on the root-window and put the window ID into it. The second application then retrieves the property, whose name it also knows, and then can draw whatever it wants into the window. [Note: this scheme works iff there is only one instance of the first application running, and the scheme is subject to the limitations mentioned in the Question about using window IDs on remote displays.] Note also that you will still need to coordinate any higher-level cooperation among your applications. Note also that two processes can share a window but should not try to use the same server connection. If one process is a child of the other, it should close down the connection to the server and open its own connection. [mostly courtesy Phil Karlton (karlton@wpd.sgi.com) 6/90] ---------------------------------------------------------------------- Subject: 144) Why can't my program work with tvtwm or swm? A number of applications, including xwd, xwininfo, and xsetroot, do not handle the virtual root window which tvtwm and swm use; they typically return the wrong child of root. A general solution is to add this code or to use it in your own application where you would normally use RootWindow(dpy,screen): /* Function Name: GetVRoot * Description: Gets the root window, even if it's a virtual root * Arguments: the display and the screen * Returns: the root window for the client */ #include <X11/Xatom.h> Window GetVRoot(dpy, scr) Display *dpy; int scr; { Window rootReturn, parentReturn, *children; unsigned int numChildren; Window root = RootWindow(dpy, scr); Atom __SWM_VROOT = None; int i; __SWM_VROOT = XInternAtom(dpy, "__SWM_VROOT", False); XQueryTree(dpy, root, &rootReturn, &parentReturn, &children, &numChildren); for (i = 0; i < numChildren; i++) { Atom actual_type; int actual_format; long nitems, bytesafter; Window *newRoot = NULL; if (XGetWindowProperty(dpy, children[i], __SWM_VROOT, 0, 1, False, XA_WINDOW, &actual_type, &actual_format, &nitems, &bytesafter, (unsigned char **) &newRoot) == Success && newRoot) { root = *newRoot; break; } } return root; } [courtesy David Elliott (dce@smsc.sony.com). Similar code is in ssetroot, a version of xsetroot distributed with tvtwm. 2/91] A header file by Andreas Stolcke of ICSI on export.lcs.mit.edu:contrib/vroot.h functions similarly by providing macros for RootWindow and DefaultRootWindow; code can include this header file first to run properly in the presence of a virtual desktop. ---------------------------------------------------------------------- Subject: 145) How do I keep a window from being resized by the user? Resizing the window is done through the window manager; window managers can pay attention to the size hints your application places on the window, but there is no guarantee that the window manager will listen. You can try setting the minimum and maximum size hints to your target size and hope for the best. [1/91] ---------------------------------------------------------------------- Subject: 146) How do I keep a window in the foreground at all times? It's rather antisocial for an application to constantly raise itself [e.g. by tracking VisibilityNotify events] so that it isn't overlapped -- imagine the conflict between two such programs running. The only sure way to have your window appear on the top of the stack is to make the window override-redirect; this means that you are temporarily assuming window-management duties while the window is up, so you want to do this infrequently and then only for short periods of time (e.g. for popup menus or other short parameter-setting windows). [thanks to der Mouse (mouse@larry.mcrcim.mcgill.edu); 7/92] ---------------------------------------------------------------------- Subject: 147) How do I make text and bitmaps blink in X? There is no easy way. Unless you're willing to depend on some sort of extension (as yet non-existent), you have to arrange for the blinking yourself, either by redrawing the contents periodically or, if possible, by playing games with the colormap and changing the color of the contents. [Thanks to mouse@larry.mcrcim.mcgill.edu (der Mouse), 7/91] ---------------------------------------------------------------------- Subject: 148) How do I render rotated text? Xlib intentionally does not provide such sophisticated graphics capabilities, leaving them up to server-extensions or clients-side graphics libraries. Your only choice, if you want to stay within the core X protocol, is to render the text into a pixmap, read it back via XGetImage(), rotate it "by hand" with whatever matrices you want, and put it back to the server via XPutImage(); more specifically: 1) create a bitmap B and write your text to it. 2) create an XYBitmap image I from B (via XGetImage). 3) create an XYBitmap Image I2 big enough to handle the transformation. 4) for each x,y in I2, I2(x,y) = I(a,b) where a = x * cos(theta) - y * sin(theta) b = x * sin(theta) + y * cos(theta) 5) render I2 Note that you should be careful how you implement this not to lose bits; an algorithm based on shear transformations may in fact be better. The high-level server-extensions and graphics packages available for X also permit rendering of rotated text: Display PostScript, PEX, PHiGS, and GKS, although most are not capable of arbitrary rotation and probably do not use the same fonts that would be found on a printer. In addition, if you have enough access to the server to install a font on it, you can create a font which consists of letters rotated at some predefined angle. Your application can then itself figure out placement of each glyph. [courtesy der Mouse (mouse@larry.mcrcim.mcgill.edu), Eric Taylor (etaylor@wilkins.bmc.tmc.edu), and Ken Lee (klee@wsl.dec.com), 11/90; Liam Quin (lee@sq.com), 12/90] InterViews (C++ UI toolkit, in the X contrib software) has support for rendering rotated fonts in X. It could be one source of example code. [Brian R. Smith (brsmith@cs.umn.edu), 3/91] Another possibility is to use the Hershey Fonts; they are stroke-rendered and can be used by X by converting them into XDrawLine requests. [eric@pencom.com, 10/91] The xrotfont program by Alan Richardson (mppa3@syma.sussex.ac.uk) (posted to comp.sources.x July 14 1992) paints a rotated font by implementing the method above and by using an outline (Hershey) font. O'Reilly's X Resource Volume 3 includes information from HP about modifications to the X fonts server which provide for rotated and scaled text. ---------------------------------------------------------------------- Subject: 149) What is the X Registry? (How do I reserve names?) There are places in the X Toolkit, in applications, and in the X protocol that define and use string names. The context is such that conflicts are possible if different components use the same name for different things. The MIT X Consortium maintains a registry of names in these domains: orgainization names, selection names, selection targets, resource types, application classes, and class extension record types; and several others. The list as of 7/91 is in the directory mit/doc/Registry on the R5 tape; it is also available by sending "send docs registry" to the xstuff mail server. To register names (first come, first served) or to ask questions send to xregistry@expo.lcs.mit.edu; be sure to include a postal address for confirmation. [11/90; condensed from Asente/Swick Appendix H] ---------------------------------------------------------------------- David B. Lewis faq%craft@uunet.uu.net "Just the FAQs, ma'am." -- Joe Friday -- David B. Lewis Temporarily at but not speaking for Visual, Inc. day: dbl@visual.com evening: david%craft@uunet.uu.net Xref: bloom-picayune.mit.edu comp.windows.x:62130 news.answers:4669 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!news.bbn.com!olivea!sun-barr!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!gumby!destroyer!cs.ubc.ca!alberta!art From: art@cs.UAlberta.CA (Art Mulder) Newsgroups: comp.windows.x,news.answers Subject: comp.windows.x: Getting more performance out of X. FAQ Summary: This posting contains a list of suggestions about what you can do to get the best performance out of X on your workstation -- without buying more hardware. Keywords: FAQ speed X Message-ID: <art.724532420@warspite> Date: 16 Dec 92 19:00:20 GMT Sender: news@cs.UAlberta.CA (News Administrator) Reply-To: art@cs.ualberta.ca (Art Mulder) Followup-To: poster Organization: University of Alberta, Edmonton, Canada Lines: 556 Approved: news-answers-request@MIT.Edu Nntp-Posting-Host: warspite.cs.ualberta.ca Archive-name: x-faq/speedups Last-modified: 1992/12/16 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - HOW TO MAXIMIZE THE PERFORMANCE OF X -- monthly posting More RAM, Faster CPU's, More disk space, Faster Ethernet... These are the standard responses you get when you ask about how to make your workstation go faster. Well, more hardware isn't always an option, and I wonder if more hardware is really always even a necessity. This "FAQ" list is a collection of suggestions and ideas from different people on the net on how you can the best possible performance from your workstation, WITHOUT PURCHASING MORE HARDWARE. This document is specifically concerned with X. I realize that there are a whole host of other factors that affect the performance of a workstation. Perhaps at some point, this document will grow into a generalized "System Performance Tuning" document, but for now our focus is on X. [ Note: People seriously interested in the whole area of system performance, might want to look at the O'Reilly nutshell book "System Performance Tuning" by Mike Loukides. I've seen it, but not read it, so I can't comment on its content. --ed.] ----------------- Table of Contents ----------------- 1. What about the "Other X FAQ"? ! 2. Window Managers 3. The X Server Which Server? Starting your Server Fonts ! About the Resources File Define Your Display Properly ! 4. Clients ! A Better Clock for X A Better Terminal Emulator for X 5. Miscellaneous Suggestions Pretty Pictures A Quicker Mouse Programming Thoughts ! Say What!? 6. Other Sources of Information 7. Author & Notes ----------------------------- What about the "Other X FAQ"? ----------------------------- David B. Lewis (faq%craft@uunet.uu.net) maintains the informative and well written "comp.windows.x Frequently Asked Questions" document. Its focus though, is on generally useful X information, while this FAQ is concerned with the issue of performance. The comp.windows.x FAQ does address the issue of speed, but only with regards to the X server. The gist of that topic seems to be: "Use X11R5, it is faster than R4". (Please see the X FAQ for complete details). Performance is a subjective issue. The individual user must balance `speed' versus `features' in order to come to a personal decision. Therefore this document can be be expected to contain many subjective opinions in and amongst the objective facts. --------------- Window Managers --------------- There are a lot of window managers out there, with lots of different features and abilities. The choice of which to use is by necessity a balancing act between performance and useful features. At this point, most respondents have agreed upon "twm" as the best candidate for a speedy window manager. A couple of generic tricks you can try is turning off unnecessary things like "zooming" and "opaque move". Also, if you lay out your windows in a tiled maner, you reduce the amount of cpu power spent in raising and lowering windows. Joe English (joe@trystero.art.com) I've found that a good font for tiling is 7x13 (aka: -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1 ) It is the biggest font I have found that I can use on a SPARC ELC and still get two 80 column terminal windows side-by-side on the display with no overlap. Other suggestions will be accepted. ------------ The X Server ------------ Which Server? - - - - - - - Doesn't the old saying go: "Use the right tool for the job"? This applies to the X11 server also. Make sure that your server is a proper match for your hardware platform. If you have a monochrome monitor, use a monochrome X11 server. On my Monochrome Sun ELC, I haven't noticed much difference between the Xsun (colour) server and XsunMono, however it was pointed out to me that XsunMono is about 800k smaller and therefore should contribute to less paging. [ thanks to: Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk), Michael Salmon (Michael.Salmon@eos.ericsson.se) ] How your server was compiled can also make a difference. Jeff Law (law@schirf.cs.utah.edu) advises us that on a Sun system, X should be compiled with gcc2.* or with the unbundled Sun compiler, and *not* use the the SunOS 4.1.1 bundled compiler. You can expect to get "*very* large speedups in the server" that way. I would assume that similar results would occur if you used one of the other popular high-quality commercial compilers on the market. Starting your Server - - - - - - - - - - - Joe English (joe@trystero.art.com) : If you start up a lot of clients in your .xsession or whatever, sleep for a second or two after launching each one. After I changed my .xclients script to do this, logging in actually took *less* time... we have a heavily loaded system without much core, though. This sounds crazy, but I tried it, and it works! Warner Losh (imp@Solbourne.COM) provided me with a good explanation of why this works, which I have summarized here: When you start up an X server it takes a huge amount of time to start accepting connections. A lot of initialization is done by the server when it starts. This process touches a large number of pages. Any other process running at the same time would fight the server for use of the CPU, and more importantly, memory. If you put a sleep in there, you give the Server a chance to get itself sorted out before the clients start up. Similarly, there is also a lot of initialization whenever an X client program starts: toolkits registering widgets, resources being fetched, programs initializing state and "databases" and so forth. All this activity is typically memory intensive. Once this initialization is done ("The process has reached a steady state"), the memory usage typically settles down to using only a few pages. So, by using sleeps to stagger the launching of your clients in your .Xinitrc , you avoid them "fighting" each other over your workstations limited resources This is most definitely a "Your Mileage May Vary" situation, as there are so many variables to be considered: available RAM, local swap space, load average, number of users on your system, which clients you are starting, etc. Currently in my .xinitrc I have a situation like: (sleep 1; exec xclock ) & (sleep 1; exec xbiff ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & I've experimented with: (sleep 1; exec xclock ) & (sleep 2; exec xbiff ) & (sleep 3; exec xterm ) & (sleep 4; exec xterm ) & (sleep 5; exec xterm ) & I've even tried: (sleep 2; exec start_X_clients_script ) & and then in start_X_clients_script I had: (sleep 1; exec xclock ) & (sleep 1; exec xbiff ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & [ The idea with this last one was to make sure that xinit had completely finished processing my .xinitrc, and had settled down into a "steady state" before the sleep expired and all my clients were launched. ] All of these yielded fairly comparable results, and so I just stuck with my current setup, for its simplicity. You will probably have to experiment a bit to find a setup which suits you. Fonts - - - Loading fonts takes time, and RAM. If you minimize the number of fonts your applications use, you'll get speed increases in load-up time. Farrell McKay (fbm@ptcburp.ptcbu.oz.au) : One small point I've noticed (not specifically related to R5) is that clients will always start up more quickly if they don't have to load a new font into the server. So I only use two or three fonts throughout the whole of my X environment. Sometimes I need to use a Kanji font (for my work) at intervals throughout the day, so in the morning I start up xfd with that font (that loads it into the server), iconify it, and leave it there for the rest of the day. Pre-loaded fonts sure cut down initialization time. Joe English (joe@trystero.art.com) : Carefully choose a small number of fonts (one fixed-width, one roman, one sans-serif, one large one, whatever else you need) and reconfigure all the applications you use to use only those fonts. This will conserve server resources and make applications start up faster. Loading fonts takes a long time. 
